add a comment as to why this is needed.

and why is this needed? Also why is the log level changed?

The comment "PSA doesn't work with WPA3 builtin (uses bignum)" could be misleading since this PR introduces WPA3 PSA support. Consider updating the comment to clarify:

# PSA doesn't work with WPA3 builtin implementation (uses bignum)
# Use HOSTAP_CRYPTO_WPA3_PSA for WPA3 support with PSA

The removal of :STRING= from the EXTRA_CONF_FILE line changes the CMake variable type specification. This could potentially affect how the variable is processed. Ensure this change is intentional and that the build system correctly handles the untyped variable assignment.

The error handling logic in wpa3_psa_derive_pt_group is incorrect. When group is not 0, the function immediately returns NULL for any non-zero group value, even when group == 19 (which should be the only supported value).

The logic should be:

if (group == 0) {
    wpa_printf(MSG_DEBUG, "WPA3-PSA: PT derivation - Group 0 (auto-select) - using group 19 (NIST P-256)");
    group = 19;
} else if (group != 19) {
    wpa_printf(MSG_DEBUG, "WPA3-PSA: Unsupported group %d for PT derivation (only group 19 NIST P-256 supported)", group);
    return NULL;
}

Memory leak: If the PT structure is successfully allocated but there is a next PT in the chain, the function sae_deinit_pt only frees the first PT structure and doesn't traverse the linked list. This will leak memory for any additional PT structures in the chain.

The function should recursively free all PT structures in the linked list:

void sae_deinit_pt(struct sae_pt *pt)
{
    struct sae_pt *next;
    
    while (pt) {
        next = pt->next;
        os_free(pt);
        pt = next;
    }
}

Incorrect borrow detection logic. The condition (value[i] == modulus[i] && borrow) is checking if values are equal AND there's a borrow, but the borrow flag should be set when the subtraction underflows. The correct logic should check if the subtraction result is greater than the original value (indicating underflow):

diff = (uint32_t)value[i] - (uint32_t)modulus[i] - borrow;
borrow = (diff > 0xFF) ? 1 : 0;
value[i] = diff & 0xFF;

The current implementation may incorrectly set the borrow flag.

Configuration conflict: CONFIG_NRF_WIFI_DATA_HEAP_SIZE is set to 80000 in overlay-enterprise.conf (line 1) but overridden to 90000 in sample.yaml (line 21). This creates confusion about which value should be used. Consider either:

1. Removing the setting from one location
2. Using a single consistent value
3. Documenting why different values are needed in different contexts

Using pull/3452/head as a revision is not a valid permanent reference for production code. Pull request references are temporary and will become invalid once the PR is merged or closed. This should be changed to a specific commit SHA or a stable branch/tag reference.

Replace with a concrete commit SHA:

revision: <commit_sha>

The error handling logic in sae_set_group is incorrect. When group is not 0, the function immediately returns an error for any non-zero group value, even when group == 19 (which should be the only supported value).

The logic should be:

if (group == 0) {
    group = 19;
} else if (group != 19) {
    wpa_printf(MSG_ERROR, "WPA3-PSA: Only group 19 (NIST P-256) is supported, got %d", group);
    return -1;
}

The buffer size validation uses a magic number 98 without explanation. This should be defined as a named constant to improve code maintainability and clarity. Consider defining:

#define WPA3_SAE_COMMIT_MESSAGE_LEN 98  /* [group(2)][scalar(32)][element(64)] */

Then use this constant throughout the code instead of the hardcoded value.

The magic numbers 32 for NIST P-256 scalar/field sizes and buffer sizes appear throughout the code without named constants. This reduces maintainability. Consider defining constants such as:

#define WPA3_SAE_P256_SCALAR_LEN 32
#define WPA3_SAE_P256_ELEMENT_X_LEN 32
#define WPA3_SAE_P256_ELEMENT_Y_LEN 32

This would make the code more self-documenting and easier to maintain.

The comment states "No GDH (Group-Dependent Hash) support" but the code includes GDH support logic (see lines 996-1002 with PSA_ALG_WPA3_SAE_GDH). This documentation is inconsistent with the implementation.

The hard-coded value 32 for SSID length validation should be defined as a named constant (e.g., WPA3_PSA_MAX_SSID_LEN) for better maintainability, especially since it's also used at line 55 for the ssid array size.

Hard-coded buffer size 1024 is used for commit_data without justification. This should be defined as a named constant, ideally reusing the already defined WPA3_PSA_MAX_COMMIT_LEN constant from line 31.

Hard-coded send_confirm_counter value {0x01, 0x00} appears to be little-endian representation of 1, but this is not documented. Add a comment explaining the byte order and why this specific encoding is required by the protocol.

Memory allocation uses os_malloc(32) with a hard-coded size. This should use a named constant representing the expected PMK size, or better yet, use the size from PSA APIs to avoid assumptions about the key size.

Hard-coded buffer sizes (256 bytes) are used throughout the code without clear justification. Consider defining named constants (e.g., WPA3_PSA_MAX_PASSWORD_LEN, WPA3_PSA_MAX_SHARED_KEY_LEN) to make the code more maintainable and document the rationale for these sizes.

The same hard-coded value 98 appears again for commit size validation. This duplication (also at line 349, 389, 1174) reinforces the need for a named constant to avoid maintenance issues.

Redundant code: The same key type PSA_KEY_TYPE_PASSWORD is set for both H2E and non-H2E cases. Either the conditional is unnecessary, or different key types should be used for different modes. If they're truly the same, remove the conditional and consolidate the logic.

The send_confirm field is initialized to 1 with a comment stating "not 0", but this magic number needs clarification. Consider adding a more detailed comment explaining why the initial value must be 1 according to the SAE protocol specification.

[nitpick] Inconsistent hyphenation: The documentation uses "peer-to-peer" (with hyphens) in line 10 but "device-to-device" (also with hyphens) in the same sentence. While both are correct, consider using consistent terminology throughout. The industry standard term is "peer-to-peer" or "P2P".